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PREFACE 


The  Automated  Guideway  Transit  Technology  (AGTT)  System 
Operations  Studies  (SOS)  program,  sponsored  by  the  Urban  Mass 
Transportation  Administration  (UMTA) , has  resulted  in  a 
comprehensive  set  of  AGT  system  planning  and  development 
models.  In  order  to  maximize  the  benefits  resulting  from  the 

availability  of  these  models,  through  their  continued  use  and 
improvement,  GM  Transportation  Systems  Center  (GM  TSC)  has 
been  awarded  a contract  by  the  Transportation  Systems  Center  of 
the  U.S.  Department  of  Transportation.  The  objectives  of  this 
effort  are  to  enhance  the  usefulness  of  the  AGTT-SOS  software 
through  continued  research  and  development  activity,  to 

increase  user  familiarity  of  and  confidence  in  the  software 

through  information  dissem-  ination  workshops  and  further 

validation,  and  to  extend  the  guideline  standards  and 
requirements  for  design  and  operation  of  AGT  systems. 


This  Plan  describes  alternate  failure  response  strategies 
and  the  software  modifications  required  to  model  them  in  the 
DPMS  and  DESM.  Specific  software  modifications  are  recommended 
to  enhance  the  failure  management  modeling  capabilities  of  the 
DPMS  and  the  DESM.  Work  performed  under  this  task  was 
supported  by  the  UMTA  Office  of  Technology  Development  and  Deploy- 
ment, Office  of  New  Systems  Applications.  The  Technical  Monitor 
for  the  project  at  DOT/TSC  was  Arthur  Priver,  who  was  assisted  by 
Li  Shin  Yuan. 


This  document  was  prepared  under  the  direction  of  the 
Extended  SOS  Program  Manager  at  GM  TSC,  James  F.  Thompson.  The 
report  was  written  by  John  F.  Duke  and  Ronald  A.  Lee  of  GM  TSC. 
John  Duke  was  responsible  for  the  final  preparation  of  the  report. 
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1.0  INTRODUCTION 


The  purpose  of  the  DPM  Failure  Management  task  is  to 
enhance  the  modeling  capabilities  of  the  DPMS  and  DESM  by 
increasing  the  failure  modeling  detail  of  these  processors  so 
that  a variety  of  failure  management  strategies  can  be 
evaluated  in  terms  of  total  vehicle  and  passenger  delay.  The 
purposes  of  this  planning  document  are  to  list  the  major 
failure  management  strategies  that  are  currently  being 
considered  in  engineering  studies  of  Downtown  People  Movers  and 
to  propose  software  modifications,  in  functional  terms,  and 
analysis  techniques  which  will  permit  modeling  of  as  many  of 
these  strategies  as  possible. 

The  existing  failure  management  strategies  in  the  DESM/DPMS 
are  detailed  first  and  then  failure  management  strategies  which 
have  been  considered  in  detail  by  DPM  planners  and  engineers  in 
Los  Angeles,  St.  Paul,  and  Detroit  DPM  systems  are  presented. 
The  software  modifications  necessary  to  implement  the  various 
strategies  are  described  and  assessed  for  feasible  implemen- 
tation within  the  allocated  task  resources. 

The  final  section  of  this  plan  presents  the  schedule  and  an 
estimate  of  project  resources  required  to  complete  the  task. 
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2.0  CURRENT  FAILURE  MODELING 


The  DESM  and  DPMS  are  general  purpose  discrete  event 
simulation  processors  used  to  model  the  actions  and  inter- 
actions of  automated  guideway  systems  such  as  Downtown  People 
Movers.  The  failure  and  failure  response  models  provided  in 
the  DESM/DPMS  are  generalized  to  represent  a variety  of  failure 
and  degradation  situations.  However,  it  is  possible  to  model 
more  specific  failure  management  strategies  through  a moderate 
level  of  code  modification  to  the  DESM/DPMS. 


Failures  can  be  specified  by  the  DESM/DPMS  user  for  any  of 
the  entities  listed  below: 


1.  Guideway  links  - either  entry,  exit,  or  the  entire  link 

2.  Station  links  - either  entry,  exit,  or  the  entire  link 

3.  Stations  - the  entire  station  is  failed  by  not  allowing 
entry  to  the  input  ramp  and  exit  from  the  output  ramp; 
movement  on  other  station  links  continues. 

These  are  not  vehicle  failures,  as  such;  however,  they  can  be 
interpreted  as  vehicle  failures  because  the  first  vehicle  to 
encounter  the  failure  condition  stops,  and  subsequent  vehicles 
queue  behind  the  stopped  vehicle  exactly  as  if  the  vehicle 
itself  had  failed.  In  the  case  of  guideway  link  failures,  the 
minimum  path  algorithm  is  re-executed  with  an  artificially  high 
travel  "cost"  on  the  failed  link  in  order  to  reroute  future 
paths  around  the  failed  link,  if  possible. 


Vehicle  degraded  operation  may  also  be  specified  by 
defining  a guideway  link  entry  or  exit  where  the  next  vehicle 
to  pass  will  go  into  degraded  operation.  In  this  case,  the 
degraded  vehicle  "limps"  to  the  closest  station,  deboards  all 
of  its  passengers,  and  disappears  from  the  simulation. 

The  user  of  the  model  specifies  the  time  duration  of  a failure 
by  giving  a failure  recovery  time.  At  recovery,  vehicles  are  re- 
started and  continue  their  operations  as  if  no  failure  had  occurred. 
Degradation  is  in  force  until  a user-specified  degradation 
recovery  time  or  until  a vehicle  enteres  degradation  mode, 
whichever  occurs  first.  The  following  table  sumarizes  the 
effects  of  failures  and  degradations  on  the  vehicle  fleet  and 
the  set  of  passengers  in  the  current  DESM/DPMS. 

1.  Failed  vehicle 

• Vehicle  stops. 

• Passengers  remain  on-board. 

• At  recovery  vehicle  restarts  and  continues  as  if  no 
failure  had  occurred. 
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2. 


Degraded  vehicle 

• Vehicle  travels  at  reduced  speed  to  closest  station. 

• All  passengers  deboard  as  completed  trips  (a  con- 
stant penalty  time  is  added  to  the  trip  time  of 
those  passengers  who  have  not  reached  their  desired 
destination) . 

• Vehicle  is  removed  from  the  simulation. 

• No  vehicle  spacing  adjustment  is  made  for  scheduled 
service . 


3.  Other  vehicles 

• Vehicles  continue  in  normal  service  as  if  no  fail- 
ure or  degradation  occurred. 

• If  a link  is  blocked,  an  alternate  path,  as 
determined  by  minimum  path  algorithm,  is  followed. 

• If  no  alternate,  vehicles  queue  until  recovery  re- 
leases blockage. 

• No  passengers  are  deboarded  prematurely. 

• No  stops  are  skipped  unless  an  off-line  station  is 
blocked;  then,  passengers  who  miss  destination  are 
deboarded  at  the  next  stop  as  completed  trips  (a 
constant  penalty  time  is  added  to  the  trip  time  of 
those  passengers  who  have  not  reached  their  desired 
destination) . 
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GENERAL  SOFTWARE  IMPROVEMENTS  FOR  FAILURE  MODELING 


3.  0 


While  the  generalized  failure  and  degradation  processing 
present  in  the  DESM/DPMS  provides  an  acceptable  model  for 
failure  occurrences,  it  became  apparent  during  AGTT-SOS 
analyses  that  the  recovery  models  are  too  simplistic  to  model 
particular  recovery  strategies  in  detail.  Therefore,  the 
following  areas  have  been  identified  for  software  modification 
in  order  to  better  model  failure  and  degradation  recoveries  in 
more  general  cases. 

The  current  dispatch  algorithms  under  scheduled  service  do 
not  result  in  an  effective  debunching  control  after  queue 
buildup  resulting  from  either  a failure  or  congestion.  A 

related  problem  is  that  there  is  no  slack  time  built  into  the 
schedules.  Route  spacing  headways  are  based  on  minimum  travel 
times  and  minimum  board -deboard  times.  Therefore,  once  a 

vehicle  falls  behind  schedule,  it  remains  behind  schedule. 
Vehicle  spacing  by  fixed  schedule  dispatch  requires  that  each 

vehicle  be  dispatched  one  headway  time  from  scheduled  launch 
time  of  the  previous  vehicle  dispatched  on  the  route.  The 
vehicles  are  always  trying  to  maintain  a theoretical  fixed 
schedule.  If  vehicles  fall  behind  schedule  because  of  a 
failure  or  congestion,  they  are  launched  without  delay  in  order 
to  try  to  catch  up  to  schedule.  However,  since  there  is  no 

slack  in  the  schedule,  they  are  unable  to  catch  up,  and  so  they 
continue  to  be  launched  from  each  station  without  schedule 
delay.  Thus,  any  bunching  that  occurs  during  the  failure  is 
perpetuated  under  the  fixed  schedule  dispatch. 


independent  software  modifications  are  recommended  to 
the  fixed  schedule  dispatch  algorithm.  First,  the 
to  add  slack  to  the  route  spacing  schedules  will  be 
the  software  by  specifying  a minimum  dwell  time  at  the 

than  the  minimum  board-deboard  time, 
modification  will  be  coordinated  with 
has  made  in  the  board-deboard 
With  slack  in  the  schedules,  vehicles  will  be 
stations  during  uncongested  operation  until 
scheduled  dispatch  time  thus  decreasing  system  capacity,  but 
they  will  be  capable  of  catching  up  to  schedule  through  a 
series  of  undelayed  dispatches  following  a failure  condition. 


Two 
improve 
ability 
added  to 
station  that 
This  minimum 
the  changes 
calculations . 
delayed  at 


is  larger 
dwell  time 
DOT-TSC 


The  second  software  modification,  independent  of  the  first, 
would  define  an  additional  fixed  schedule  dispatch,  called 
fixed  separation  dispatch.  In  this  algorithm,  vehicles  would 
be  scheduled  for  dispatch  one  route  headway  behind  the  actual 
previous  dispatch  on  the  route  rather  than  the  scheduled 
previous  dispatch.  This  algorithm  would  limit  capacity  since 
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any  vehicle  delay  would  ripple  back  through  the  entire  fleet. 
However,  the  algorithm  would  maintain  an  almost  constant 
separation  among  the  vehicles  on  the  routes,  and  it  would 
effect  a rapid  debunching  after  congestion  due  to  failure. 

The  currently  implemented  midpoint  schedule  dispatch 
algorithm  attempts  to  avoid  bunching  by  specifying  the 

scheduled  dispatch  time  as  the  midpoint  of  the  actual  departure 
time  of  the  previous  vehicle  and  the  next  fixed  schedule 
departure  time.  This  is  an  ineffective  dispatch  algorithm 
after  a failure  because  vehicles  are  still  trying  to  catch  up 
to  a theoretical  fixed  schedule  which  assumes  no  failures. 
This  algorithm  would  be  effective  at  maintaining  reasonable 
spacing  in  a noncongestion  situation  in  a schedule  including 
slack  because  it  would  moderately  respace  vehicles  which  run 
ahead  of  schedule. 

We  also  recommend  a third  software  modification, 
independent  of  the  first  two,  to  define  an  additional  midpoint 
dispatch,  called  midpoint  separation  dispatch.  In  this 
algorithm,  vehicles  would  be  scheduled  for  dispatch  midway 
between  the  actual  departure  time  of  the  previous  vehicle  and 
the  current  time  plus  one  route  headway.  This  algorithm  would 
effect  an  orderly  debunching  of  vehicles  following  a failure  or 
congestion  situation  while  maintaining  more  system  capacity 
than  the  fixed  separation  dispatch  algorithm  described  above. 

The  implementation  of  these  software  modifications  would 
provide  the  DESM/DPMS  user  eight  schedule  dispatch  combinations 
instead  of  the  present  two  as  shown  below. 


Dispatch  Algorithm 


Fixed 
Fixed 
Fixed 
Fixed 
Midpoint 
Midpo int 


schedule 
schedule 
separation 
separation 
schedule 
schedule 


Midpoint 

Midpoint 


separat ion 
separation 


Slack  in  Schedule 

Yes 

No 

Yes 

No 

Yes 

No 

Yes 

No 


Currently  Available 

No 

Yes 

No 

No 

No 

Yes 

No 

No 


The  current  implementation  of 
does  not  effectively  model  the 
vehicle  in  scheduled  service. 


active  fleet  size  changes 
replacement  of  a degraded 
A degraded  vehicle  will 


can 


disappear  from  the  simulation  at  the  first  station  encountered 
but  a replacement 
change.  However, 
changes,  a whole 
existing  vehicles 
removed  from  the 


only  be  entered  as  an 
for  scheduled  service 
new  fleet  of  vehicles 
go  into  a deboard-only 
simulation.  While  this 
marginally  acceptable  to  model  scheduled 
changes  if  data  from  the  transition  period 


active  fleet  size 
active  fleet  size 
is  started  while 
mode  and  are  then 
implementation  is 
service  fleet  size 
are  noncritical,  the 
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transition  period  following  a failure  and  subsequent  replace- 
ment vehicle  launching  is  likely  to  be  important;  therefore, 
the  need  clearly  exists  for  an  improved  algorithm.  Assuming 
that  an  adequate  debunching  algorithm  is  implemented  for 
scheduled  service  dispatch,  the  need  to  dispatch  an  entire  new 
fleet  of  vehicles  will  be  obviated.  A much  simpler  active 
fleet  size  change  algorithm  can  be  implemented  which  only 
recalculates  scheduled  route  parameters,  such  as  number  of 
vehicles  on  the  route  and  route  headway,  and  relies  on  the 
dispatch  algorithms  to  relieve  any  bunching  effects  which 
result  from  a changed  number  of  vehicles  on  a set  cycle  period 
route.  Software  modifications  will  also  be  implemented  to 
model  the  transition  from  one  consist  size  to  another  on  a 
route . 


The  additional  scheduled  dispatch  algorithms  can  be  added 
to  the  existing  code  as  options  selected  by  the  user  and  can  be 
coded  entirely  within  existing  variables.  The  addition  of  a 
minimum  dwell  time  parameter  for  stations  will  likely  introduce 
a new  variable  and  will  generate  changes  in  both  input  and 
model  processor  code  segments.  The  changes  in  active  fleet 
size  management  will  require  extensive  study  of  existing  code 
to  identify  the  effects  of  these  functional  changes. 
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4.0  ALTERNATIVE  FAILURE  RESPONSE  STRATEGIES 


The  failure  management  strategies  which  are  being  consid- 
ered by  DPM  planners  and  engineer  s^-  • 2 > 3 include  various 
failed  vehicle  recovery  alternatives,  strategic  location  of 
turnbacks  and  sidings,  and  the  ability  to  reconfigure  network 
operation.  Since  failures  which  result  in  vehicle  stoppage  or 
degradation  are  most  disruptive  to  network  operation  and 
passenger  service,  these  types  of  failures  and  detailed  system 
responses  to  them  are  important  areas  of  concern.  The  UMTA  DPM 
guidelines^  identify  the  following  failed  vehicle  recovery 
strategies  which  should  be  considered  in  the  design  of  DPM 
systems : 

1.  Automatic  operation  restart 

2.  On-board  manual  control 

3.  Towing  or  pushing  by  another  revenue  vehicle 

4.  Towing  or  pushing  by  a guideway  service  vehicle 

5.  Hoisting  from  the  guideway 


Several  of  these  alternatives  were  analyzed  in  detail  in  con- 
junction with  network  alternatives, 
maintenance  siding,  in  the  context  of 
DPM  system. 5 in  this  analysis  the 
various  failure  recovery  strategies 
delays  were  determined  analytically. 


such  as  turnbacks  and  a 
the  proposed  Los  Angeles 
relative  effects  of  the 
in  terms  of  passenger 
The  potential  value  of  a 


detailed 
noted . 


simulation  in  the  evaluation  of  system  impacts  was 


The  DESM  or  DPMS , coupled  with 
Model  (SAM)  are  valuable  tools  which 
the  effects  of  failures  on  passenger 


the  System  Availability 
can  be  used  to  evaluate 
service.  Table  4-1  lists 


-^-Preliminary  System  Specification,  The  Los  Angeles  Downtown 
People  Mover,  The  Community  Redevelopment  Agency  of  the  City  of 
Los  Angeles,  October  1978. 

^St.  Paul  Downtown  People  Mover  Procurement  Bid  Package, 
System  Specification,  Technical  Provisions,  Draft , BRW/Kaiser 
Engineers,  October  1978. 

^Operational  Analysis  and  Failure  Management  Analysis 
(Working  Paper) , Detroit  Downtown  People  Mover  Preliminary 
Engineering  Project,  GM  Transportation  Systems  Center, 
September  1979. 

^Guidelines  for  Downtown  People  Mover  System  Design,  Appendix 
C,  Rev.  2,  DPM  System  Performance  Specification  Guidelines, 
Office  of  AGT  Applications,  UMTA,  June  1979. 

^Alternative  Failure  Management  Strategies  for  the  Los 
Angeles  Downtown  People  Mover. 
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TABLE  4-1.  ENHANCED  FAILURE  MANAGEMENT  MODELING  REQUIREMENTS 


Possible  Causes  of  Failure 

Failure  Effects 

Possible  Responses 
to  Failure 

Type  I or  Type  II  Vehicle 
failure  or  link  control 
failure 

Vehicle  stops  at  the  entry 
to  or  the  exit  from  a 
guideway  link. 

Type  I or  Type  II 
failure  response 

Link  control  failure 

Vehicles  can  neither  enter 
nor  leave  a guideway  link  . 

Type  II  failure 
response 

Type  I vehicle  failure 

A vehicle  becomes  degraded 
upon  entry  to  or  exit  from 
a guideway  link  and  can 
continue  only  at  reduced 
speed. 

Type  I failure 
response 

Type  I or  Type  II 
failure  or  link  control 
failure 

Vehicle  stops  at  the  entry 
to  or  exit  from  a station 
link . 

Type  I or  Type  II 
failure  response 

Link  control  failure 

Vehicles  can  neither  enter 
nor  leave  a station  link. 

Type  II  failure 
response 

Link  control  failure 

Vehicle  operation  on  a 
station  link  is  permitted 
only  at  reduced  speed. 

Type  II  failure 
response 

Station  or  link  control 
failure 

Vehicles  can  neither  enter 
nor  leave  a station. 

Type  II  failure 
response 

Notes 

1.  Type  I vehicle  failure  is  one  which  requires  that  the 
vehicle  be  removed  from  service  for  repair. 

2.  Type  I failure  response  is  one  which  involves  the  removal  of 
a vehicle  from  service,  the  transfer  of  affected  passengers, 
and  the  dispatch  of  a replacement  vehicle. 

3.  Type  II  vehicle  failure  is  one  in  which  the  vehicle  remains 
in  service  after  being  quickly  repaired  in  the  field. 

4.  Type  II  failure  response  is  one  in  which  the  system  is 
simply  restarted  under  the  operation  of  an  effective 
debunch ing  algorithm. 
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the  general  requirements  for  failure  management  modeling  as 
they  are  currently  perceived.  For  each  failure  effect  which  is 
to  be  modeled  in  the  simulation,  the  table  lists  possible 
causes  in  very  general  terms.  While  it  is  not  proposed  that 
the  causes  of  failure  be  modeled  explicitly,  they  must  be 
considered  by  the  analyst  to  specify  appropriate  failure 
responses  and  later  to  estimate  the  frequency  with  which  each 
failure  and  its  associated  effect  occur  during  the  course  of 
system  operation.  The  causes  of  failure  are  grouped  into  three 
general  categories  --  two  types  of  vehicle  failures  plus 
control  system  failures  which  cause  vehicles  to  stop  on  the 
guideway.  A Type  I vehicle  failure  is  one  which  requires  that 
the  vehicle  be  removed  from  service.  Type  II  vehicle  failures 
and  control  system  failures  can  be  repaired  in  the  field  and  do 
not  require  that  vehicles  be  removed  from  service.  The  failure 
effects  listed  in  the  table  encompass  the  consequences  which 
are  expected  to  significantly  impact  passenger  delay.  All  of 
these  failure  effects  are  currently  modeled  in  the  DESM  and 
DPMS.  Thus,  the  enhancement  of  modeling  capability  which  is 
needed  to  permit  more  detailed  analysis  of  failure  management 
alternatives  is  not  in  the  modeling  of  failures  but  rather  in 
the  modeling  of  failure  responses.  Responses  to  failures  fall 
into  two  general  categories.  A Type  I failure  response  is  a 
rather  complicated  one  which  involves  the  removal  of  a vehicle 
from  service,  the  transfer  of  passengers  from  a failed  vehicle 
to  another  revenue  service  vehicle,  and  the  dispatch  of  a 
replacement  vehicle.  A Type  II  failure  response  is  one  in 
failure  is  corrected,  and  the  system  is  simply 
In  both  cases  an  effective  debunching  algorithm  is 
restore  system  operation  to  its  former  state. 


which  the 
restarted . 
required  to 


The  purpose  of  this  section  is  to  describe  alternate 
failure  recovery  strategies  which  are  responsive  to  both  the 
UMTA  guidelines  and  the  modeling  requirements.  The  strategies 
are  described  in  terms  of  possible  responses  of  system  entities 
(vehicles  and  passengers)  to  various  types  of  failure  events. 


Type  II  failure  responses,  ones  that  do  not  involve  the 
removal  of  vehicles  from  service,  can  be  modeled  through  the 
specification  of  special  events  for  the  following  system 
entities : 

1.  Vehicles  which  are  initially  immobilized  by  the  failure 

2.  Other  vehicles 

3.  Passengers 


Vehicles  which  are  at  the  fa 
failure  remain  immobilized 
initiated.  Failure  recovery 
vehicle  affected  by  the  failure 


ilure  location 
until  failur 
is  initiated 
begins  to  move 


at  the  time 
e recovery 


when  the 
again . 1 2 3 


fi 


r 


of 

is 

st 


•'■In  the  case  of  a 
vehicles  continue  in 
at  reduced  velocity, 
of  recovery  travel  at 


degradation  failure  of  a station  link, 
motion  across  the  link,  but  they  operate 
Vehicles  entering  the  link  after  the  time 
normal  link  velocity. 
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Possible  responses  of  other  vehicles  whose  routes  cross  the 
failure  location  include: 


1.  Continue  in  revenue  service  using  an  alternate  path  to 
bypass  the  failure  location  if  possible  until  forced  to 
queue  behind  the  failure. 


2. 


Continue 
boarding 
or  until 


traveling  on  the  route  deboarding  but  not 
passengers  until  failure  recovery  is  initiated 
forced  to  queue  behind  the  failure. 


3. 


Travel  to  the 
then  continue 
until  forced 
until  recovery 


next  station,  deboard 
without  stopping  at 
to  queue  behind  the 
is  initiated. 


all  passengers,  and 
additional  stations 
failed  vehicle  or 


4. 


Travel  to  the  next  station 
recovery  is  initiated. 


and  wait  until  failure 


The  first  response  is  modeled  in  the  current  versions  of  the 
simulations;  the  other  three  are  not  currently  modeled.  The 
third  failure  response  strategy  causes  passengers  to  be 
deboarded  at  stations  other  than  their  desired  destinations. 
To  adequately  model  this  response,  passengers  who  are  pre- 
maturely deboarded  must  be  reentered  into  the  passenger  queue 
as  failure-related  transfer  passengers.  In  the  special  case  of 
a failure  in  which  the  entry  to  an  off-line  station  is  blocked, 
passengers  who  miss  their  scheduled  stop  are  deboarded  at  the 
next  downstream  station  and  are  assigned  a travel  time 
penalty.  This  particular  response  is  currently  implemented  in 
the  software. 


The  alternative  Type  II  failure  responses  of  vehicles 
directly  affected  by  failures,  other  vehicles,  and  passengers 
are  summarized  in  Figure  4-1.  The  various  combinations  of 
these  responses  which  are  illustrated  in  the  figure  represent 
failure  response  strategies  which  may  be  considered  for  Type  II 
failures.  As  indicated  above,  the  two  responses  listed  for 
directly  affected  vehicles  and  the  first  response  listed  for 
other  vehicles  and  passengers  are  already  modeled  by  the  DPMS 
and  DESM. 


Type  I failure 
removed  from  service, 
alternatives  none  o 
current  versions  of 
five  system  entities 
many  Type  I failure 
system  entities  may 
recovery  strategy: 


responses,  in  which  failed  vehicles  are 
consist  of  a much  larger  set  of  possible 
f which  are  completely  modeled  in  the 
the  software.  Special  events  for  up  to 
must  be  considered  simultaneously  to  model 
response  strategies.  The  following  six 
be  involved  in  the  execution  of  a failure 


1.  The  failed  vehicle 

2.  Other  vehicles  in  the  system 
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FIGURE  4-1.  TYPE  II  FAILURE  RESPONSES 


3.  The  trailing  vehicle  (the  one  directly  behind  the 
failed  vehicle) 

4.  A special  recovery  or  tow  vehicle 

5.  The  spare  or  replacement  vehicle 

6.  Passengers 

The  response  of  the  failed  vehicle  itself  is  relatively 
independent  of  the  response  of  other  system  entities  and 
includes  the  following  actions: 

1.  Remains  immobilized  until  recovery  is  initiated  (this 
time  may  be  zero  if  the  vehicle  is  merely  degraded  with 
respect  to  operating  velocity) 

2.  Proceeds  to  the  next  station  at  reduced  speed 

3.  Deboards  all  passengers 


4.  Proceeds  to  the  nearest  maintenance  facility  or 
available  siding  at  reduced  speed  via  the  minimum  path 

5.  Disappears  from  the  active  fleet 


The  circumstances  under  which  the  failed  vehicle  proceeds 
to  the  next  station  and  to  maintenance  may  vary  according  to 
the  particular  strategy.  For  example,  the  vehicle  may  proceed 
under  its  own  power,  be  pushed  by  a trailing  vehicle,  or  be 
towed  by  a special  service  vehicle.  The  effect,  however, 
remains  the  same  --  the  vehicle  proceeds  at  a reduced  veloc- 
ity. One  possible  variation  occurs  if  the  failed  vehicle  is 
pushed  by  the  trailing  vehicle  and  the  trailing  vehicle  stops 
at  intermediate  stations  enroute  to  maintenance. 


Possible  responses  of  other  vehicles  in  the  network  to  the 
occurrence  of  a Type  I vehicle  failure  include  the  following: 

1.  All  vehicles  continue  in  revenue  service  using  an 
alternate  path  to  bypass  the  failure  location  if 
possible . 

2.  All  vehicles  on  affected  routes  continue  in  revenue 
service  deboarding  but  not  boarding  passengers  until 
failure  recovery  is  initiated. 


3.  All  vehicles  on  affected  routes  deboard  all  passengers 
at  the  next  station  and  continue  without  making 
additional  station  stops  until  recovery  is  initiated  or 
until  they  are  forced  to  queue  behind  the  failed 
vehicle . 

4.  All  vehicles  enter  the  next  station  on  their  route  and 
wait  until  failure  recovery  is  initiated. 
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The  first  of  these  possible  responses  is  currently  implemented 
in  the  simulation  software.  The  last  alternative  would 
seriously  restrict  the  failed  vehicle  recovery  strategies  that 
could  be  considered.  In  a deployment  with  on-line  stations, 
use  of  this  strategy  would  not  automatically  clear  a path  from 
a special  tow  vehicle  to  the  failed  vehicle.  If  the  trailing 
vehicle  must  remain  in  an  upstream  station,  it  would  not  be 
available  to  push  the  failed  vehicle.  Because  of  these 
potential  difficulties,  the  strategy  in  which  all  vehicles  stop 
at  the  next  station  until  recovery  initiation  is  not  always  a 
viable  alternative. 


The  trailing  vehicle  may  act  as  any  other  vehicle  in  the 
system,  or  it  may  assume  an  active  role  in  the  recovery 
operation  by  pushing  the  failed  vehicle.  The  following  three 
modes  of  operation  of  the  trailing  vehicle  can  be  considered 

while  it  is  pushing  the  failed  vehicle: 

1.  Pushes  the  failed  vehicle  at  reduced  speed  to  the  next 
station,  deboards  passengers,  pushes  the  failed  vehicle 
to  the  maintenance  facility  or  siding,  and  then  resumes 
revenue  service  at  nominal  speed. 

2.  Pushes  the  failed  vehicle  at  reduced  speed  to  the 

maintenance  facility  or  siding,  stopping  at  stations  on 
its  route  to  discharge  passengers  only  (no  board 
events) , and  then  resumes  revenue  service  at  nominal 
speed . 

3.  Pushes  the  failed  vehicle  at  reduced  speed  to  the 

maintenance  facility  or  siding,  stopping  at  stations  on 
its  route  to  board  and  deboard  passengers,  and  then 
resumes  revenue  service  at  nominal  speed. 

Only  the  first  alternative  was  considered  in  the  Los 
Angeles  failure  management  study.  The  two  passenger  responses 
listed  under  Type  II  failure  responses  also  apply  to  Type  I 
responses.  Passengers  who  are  prevented  from  reaching  their 

desired  destination  by  the  blockage  of  an  off-line  station 
entry  ramp  are  deboarded  at  the  next  downstream  station  and  are 
assigned  a travel  time  penalty.  When  passengers  are  deboarded 
prematurely  from  the  failed  vehicle  or  from  another  vehicle, 
the  passengers  will  enter  the  passenger  queue  as 
failure-related  transfer  passengers.  The  first  passenger 
response  is  already  modeled  in  the  DESM  and  DPMS  while  the 
second  must  be  implemented. 


The  dispatching  of  a spare  vehicle  to  replace  the  one  being 
taken  out  of  service  will  be  handled  automatically  as  a special 
function  of  the  Fleet  Size  Management  process.  Improvements  to 
the  existing  Fleet  Size  Management  algorithms  in  the  DESM  and 
DPMS  are  desirable  for  modeling  transitions  from  one  demand 
period  to  another  in  addition  to  modeling  replacement  vehicle 
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insertion.  Improvements  in  this  area  are  briefly  described  in 
a previous  subsection  of  this  plan. 


Another  vehicle  recovery  strategy  is  to  dispatch  a special 
guideway  utility  vehicle  to  tow  the  failed  vehicle  to  the  next 
station  to  deboard  passengers  and  then  on  to  the  maintenance 
facility  or  siding.  The  operation  of  a guideway  service 
vehicle  will  not  be  modeled  explicitly,  but  rather  as  a series 
of  delays  which  are  calculated  by  the  processor  and  specified 
by  the  user.  The  user  must  identify  the  links  which  define  the 
path  of  the  tow  vehicle  from  its  storage  location  to  the  point 
of  the  failure.  The  user  must  also  define  the  coupling  delay 
--  i.e.,  the  time  interval  between  when  the  tow  vehicle  arrives 
and  when  the  failed  vehicle  begins  moving.  To  implement  this 
response  the  processor  will  first  fail  the  exit  to  all  links 
which  merge  into  the  tow  vehicle  path.  The  time  required  for 
the  path  of  the  tow  vehicle  to  become  cleared  is  determined  as 
the  time  required  for  the  occupancy  of  all  the  links  along  the 
path  of  the  tow  vehicle  to  become  zero.  The  time  required  for 
the  tow  vehicle  to  access  the  failure  location  is  calculated  as 
a degradation  factor  times  the  sum  of  travel  times  on  the  links 
along  the  tow  vehicle's  path.  After  the  path  has  been  cleared, 
the  tow  vehicle  has  accessed  the  failed  vehicle,  and  the 
coupling  delay  has  elapsed,  the  failed  links  associated  with 
merge  branches  will  be  recovered,  and  the  failed  vehicle  will 
proceed  at  reduced  speed  to  the  nearest  downstream  station. 
After  deboarding  all  passengers  at  the  station,  the  failed 
vehicle  will  proceed  to  the  user  specified  maintenance  facility 
via  the  minimum  path.  A replacement  vehicle  is  launched  as 
soon  as  the  failed  vehicle  begins  moving  in  accordance  with  the 
Fleet  Size  Management  process. 

The  alternative  Type  I failure  responses  described  above 
are  summarized  in  Figure  4-2.  A complete  failure  management 
strategy  is  represented  by  a selected  response  for  each 
affected  system  entity  (failed  vehicle,  other  vehicles, 
trailing  vehicle,  tow  vehicle,  passengers,  and  replacement 
vehicle) . The  various  combinations  of  alternative  responses 
which  are  illustrated  in  the  figure  represent  the  failure 
response  strategies  which  may  be  considered  for  Type  I failures. 

Maintenance  facilities  and  sidings  can  be  modeled  as  the 
vehicle  storage  links  of  selected  passenger  stations.  The 
feasibility  of  incorporating  code  to  permit  the  specification 
of  separate  maintenance  facilities  which  have  no  passenger- 
handling capability  or  passenger  demand  will  be  investigated. 


Cross-overs  can  be  used  to  minimize  the  time  required  to 
remove  a failed  vehicle  from  the  guideway  by  reducing  the 
minimum  path  from  certain  network  locations  to  the  maintenance 
nearest  siding.  Cross-over  links  can  also  be 

a portion  of  the  tow  vehicle's  path.  In  most 
systems  the  use  of  these  cross-overs  can  be 


facility  or 
specified  as 
fixed  route 
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reserved  for  failure  responses  and  fleet  size  management  by 
specifying  station  stops  on  routes  which  preclude  the  use  of 
cross-over  links. 


In  an  actual  system,  cross-overs  could  be  used  to  permit 
reconfiguration  of  routes  to  serve  changing  demand  patterns  or 
as  a response  to  a long  term  disruption  of  regular  service  due 
to  a serious  failure.  For  example,  a loop  network  may  be 
operated  as  a set  of  shuttles  during  certain  demand  periods  or 
during  a protracted  failure.  In  the  event  of  a failure  it  may 
not  be  possible  to  serve  all  stations  in  the  network  until  the 
failure  has  been  cleared.  In  order  to  model  the  reconfig- 

uration of  system  operation  it  would  be  necessary  to  modify  the 
code  to  permit  the  time  dependent  modification  of  routes, 
transfer  characteristics,  network  configuration,  number  of 
stations,  and  demand.  Modifications  of  this  nature  would 
require  major  changes  to  the  architecture  of  the  DESM  and 
DPMS.  The  software  modifications  required  to  model  real  time 
transition  from  one  operating  mode  to  another  is  beyond  the 
scope  of  this  task.  However,  the  effects  of  various  modes  of 
system  operation  on  system  performance  can  be  assessed  by 
comparing  the  results  of  separate  simulations  of 
systems  with  the  simulation  results 


for  a reference 


reconfigured 
system. 


15 


16 


FIGURE  4-2.  TYPE  I FAILURE  RESPONSES  AND  STRATEGIES 


5.0  SOFTWARE  MODIFICATION  REQUIREMENTS  OF  ALTERNATIVE 
FAILURE  RESPONSE  STRATEGIES 


The  software  modifications  required  to  implement  the  more 
detailed  failure  recovery  strategies  described  above  in  the 
DESM/DPMS  can  be  divided  into  two  categories.  First,  modifi- 
cations are  necessary  to  implement  failure  recovery  strategies 
not  currently  present  in  the  DESM/DPMS,  and,  second,  a method 
to  enable  the  user  to  select  the  appropriate  failure  response 
is  needed.  In  the  current  DESM/DPMS  there  is  a set  response 
for  each  type  of  failure  with  only  the  time  of  recovery  set  by 
the  user,  while  the  more  detailed  failure  recovery  strategies 
will  require  a greater  number  of  user  inputs  in  order  to  choose 
which  recovery  strategy  to  follow  and  to  define  any  other 
parameters  required  by  the  chosen  strategy. 


FAILED  VEHICLE  RESPONSE  STRATEGIES 


Type  II  Failure 

The  failed  vehicle 
subsequent  restart  on  the 
software . 


response  of  immobilization  and 
guideway  is  modeled  by  the  current 


Type  I Failure 

Immobilization  of  the  failed  vehicle  until  recovery  is 
initiated  is  currently  modeled  (this  time  may  be  zero  if  the 
vehicle  is  merely  degraded  with  respect  to  operating  velocity) . 

A degraded  mode  of  operation  is  presently  implemented  which 
models  vehicle  movement  at  a reduced  velocity  to  the  next 
station,  forces  all  passengers  to  deboard  as  if  their  trips 
were  completed  but  with  a penalty  time  added,  and  removes  the 
vehicle  from  the  simulation.  Modifications  would  be  required 
to  this  mode  of  operation  to  model  the  vehicle  continuing  at  a 
reduced  speed  to  the  maintenance  facility  before  being  removed 
from  the  simulation  and  to  allow  the  prematurely  deboarded 
passengers  to  reenter  the  platform  queues  as  transfer 
passengers . 


on 


The 

the 


DESM/DPMS  currently  directs  vehicle  travel  paths  based 


vehicle  ' s 


NEXTSTAT ION. 

NEXTSTATION  is  the  next  scheduled 
demand  responsive  service,  the  NEXTSTATION 
scheduled  station  stop  on  the  vehicle's  tour, 
begins  degraded  operation  its  NEXTSTATION  is 
closest  station  (stop  or  not)  along  its  route 
deboard  its  passengers.  This  code  can  remain, 
which  then  removes  the  vehicle  from  the  simulation  must  be 
changed.  If  the  current  station  is  the  selected  maintenance 
facility,  then  the  vehicle  may  be  removed  from  service. 
Otherwise,  the  vehicle's  NEXTSTATION  is  set  to  the  selected 
maintenance  station;  thus  initiating  travel  at  a reduced  speed 
to  the  maintenance  facility  for  removal  from  the  active  fleet. 


In  scheduled  service,  the 

stop  on  the  route  list.  In 

is  the  next 

When  a vehicle 
reset  to  the 

where  it  will 

but  the  code 
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Therefore,  the  following  code  is  necessary:  check  if  the 

vehicle  has  reached  the  maintenance  station,  choose  the 
maintenance  station  as  the  NEXTSTATION  if  the  current  station 
is  not  the  maintenance  station,  and  avoid  boarding  any  new 
passengers.  The  passenger  response  after  premature  deboarding 
is  described  under  Passenger  Response  Strategies  later  in  this 
sect  ion . 


A possible  variation  exists  if  the  failed  vehicle  is  pushed 
by  a trailing  vehicle,  and  the  trailing  vehicle  continues  to 
make  revenue  service  stops  at  intermediate  stations  enroute  to 
the  maintenance  facility.  This  variation  is  fully  described 
under  Trailing  Vehicle  Response  Strategies  later  in  this 
section. 

OTHER  (UNFAILED)  VEHICLES  RESPONSE  STRATEGIES 


The  responses  of  other  vehicles  after  a failure  is 
identical  from  a software  viewpoint  for  Type  I and  Type  II 
failures.  The  currently  modeled  response  of  other  vehicles  to 
a failure  is  to  continue  in  revenue  service  until  forced  to 
queue  behind  the  failed  vehicle.  In  addition,  at  the  time  of 
the  failure,  the  minimum  path  algorithm  is  reexecuted  with  an 
artificially  high  travel  "cost"  assigned  to  the  blocked  link. 
This  will  cause  vehicles  to  travel  on  alternate  paths  around 
the  blockage  if  such  alternate  paths  exist.  If  not,  the 
vehicles  will  be  forced  to  queue  behind  the  failed  vehicle 
until  recovery.  Also  at  recovery  the  vehicle  paths  are 
restored  to  the  paths  which  existed  prior  to  the  failure. 


The  alternative  response  strategies  for  other  vehicles 
after  a failure  can  be  implemented  as  follows.  Code  to  model  a 
deboard-only  mode  of  operation  already  exists  in  the  DESM/DPMS 
to  model  scheduled  service  active  fleet  size  modification. 
This  code  could  be  invoked  for  the  after-failure  processing  of 
other  vehicles,  but  would  require  modification  to  avoid 
removing  these  vehicles  from  the  active  fleet  when  they  become 
empty.  In  addition  it  would  be  necessary  to  assure  that  this 
code  is  also  valid  for  demand  responsive  service.  An 
additional  option  would  be  to  make  this  deboard-only  operation 
valid  only  for  selected  routes  if  in  scheduled  service,  so  that 
routes  unaffected  by  the  failure  would  continue  in  revenue 
service . 


Code  to  force  vehicles  to  deboard  all  passengers  at  the 
next  station  already  exists,  but  the  subsequent  routing  of 
vehicles  along  their  routes  without  additional  station  stops 
would  require  recoding  for  the  scheduled  service  case. 
Vehicles  would  continue  to  be  assigned  a NEXTSTATION  from  their 
route  list,  but  the  code  to  choose  whether  or  not  to  enter  a 
station  would  need  revision  to  check  a flag  denoting  whether  or 
not  the  vehicle  was  merely  circulating  because  of  failure. 
Also,  code  to  pick  the  NEXTSTATION  if  not  entering  would  be 
needed.  Again,  this  mode  might  only  be  applied  to  vehicles  on 
affected  routes.  In  addition,  the  effects  of  this  guideway 
circulation  mode  on  the  schedule  and  subsequent  debunching 
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algorithm  after  recovery  need  to  be  analyzed.  For  demand 
responsive  services,  a guideway  circulation  mode  already  exists 
for  empty  vehicles,  but  some  modifications  to  the  vehicle 
selection  algorithms  will  be  required  to  reflect  the  no  board- 
ing policy  until  after  recovery. 

The  strategy  of  sending  all  vehicles  to  the  next  station  on 
their  route  to  wait  until  the  failure  recovery  can  be  modeled 
reasonably  well  with  the  existing  DESM/DPMS  code  by  simply 
failing  an  appropriate  station  link  in  each  station.  The 
vehicles  would  cease  operating  as  they  encountered  the  failed 
station  links  and  would  be  prompted  to  restart  operations  at 
station  link  recovery.  This  modeling  would  result  in  no  forced 
deboarding  of  passengers;  instead,  passengers  would  remain  on 
the  vehicles  to  wait  for  recovery.  More  detailed  modeling  of 
this  response  strategy  would  result  in  more  code  modification 
than  could  be  justified  by  any  increase  in  useful  information. 
In  addition,  this  response  strategy  could  prove  ineffective  in 
the  case  of  on-line  stations  by  blocking  the  path  of  tow 
vehicles  to  the  failed  vehicle,  as  described  in  the  previous 
sect  ion . 


TRAILING  VEHICLE  RESPONSE  STRATEGIES 
Type  II  Failure 

For  Type  II  failures,  the  trailing  vehicle  (the  one 
directly  behind  the  failed  vehicle)  is  treated  the  same  as  all 
other  vehicles  in  the  simulation  after  the  failure  since  there 
is  no  need  to  push  the  failed  vehicle. 


Type  I Failure 

For  Type  I failures,  the  trailing  vehicle  may  act  as  any 
other  vehicle  in  the  simulation,  or  it  may  assist  in  the 
recovery  by  pushing  the  failed  vehicle  to  the  maintenance 
facility.  The  DESM/DPMS  code  now  treats  the  trailing  vehicle 
as  any  other  vehicle  since  the  pushing  operation  is  not 
currently  modeled.  Software  modifications  to  model  the  three 
modes  of  pushing  by  the  trailing  vehicle  are  described  in  the 
following  paragraphs. 

Modeling  of  the  pushing  operation  by  a trailing  vehicle  is 
best  accomplished  by  coupling  the  trailing  vehicle  to  the 
failed  vehicle  and  then  matching  their  destinations.  This 
method  will  enable  the  modeling  of  the  case  where  the  trailing 
vehicle  is  to  deboard  its  passengers  at  the  first  station  and 
then  push  the  failed  vehicle  directly  to  the  maintenance 
facility.  Code  would  then  be  required  to  uncouple  the  failed 
and  trailing  vehicles  and  to  return  the  trailing  vehicle  to 
revenue  service.  For  scheduled  service,  the  trailing  vehicle 
would  be  routed  to  the  nearest  station  on  its  route,  while  in 
demand  responsive  service  its  destination  would  be  controlled 
by  the  empty  vehicle  algorithm.  Thus,  modeling  of  this  mode  of 
pushing  would  use  the  same  code  developed  to  model  failed 
vehicle  movement  to  the  maintenance  facility  except  additional 
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code  would  be  required  to  model  the  operations  after  reaching 
the  maintenance  facility. 


The  other  two  modes  of  pushing  involve  stopping  at  stations 
along  the  trailing  vehicle's  route  to  deboard  passengers  from 
the  trailing  vehicle,  in  one  case,  and  to  both  deboard  and 

board  passengers  (i.e.,  full  revenue  service),  in  the  other 
case.  The  implementation  of  these  two  pushing  modes  would 

require  extensive  software  modifications  to  accommodate  the 
general  case  of  networks  with  multiple  routes  in  the  DESM/ 

DPMS . The  major  problem  is  that  the  failed  and  trailing 

vehicles  must  be  coupled  in  order  to  maintain  contact  with  each 
other  during  guideway  and  station  link  traversal,  but  retain 
independent  destinations.  The  failed  vehicle  has  the  mainte- 

vehicle ' s 


while  the  trailing 
next  stop  on  its  scheduled 
It  appears  that  the  best  way 
of  this  type  of  train  is  to 

"push 
deter  - 


nance  facility  for  its  NEXTSTATION 
NEXTSTATION  is  determined  by  the 
route  or  demand  responsive  tour, 
to  model  the  "split  destination" 

define  an  additional  type  of  entrainment  called 
coupling".  In  "push  coupled"  mode,  the  train's  path  is 

mined  by  the  minimum  path  to  the  maintenance  facility,  but  at 
each  station  diverge,  the  NEXTSTATION  of  each  vehicle  in  the 
train  is  checked  in  order  to  determine  whether  or  not  to  stop. 
The  code  involved  in  the  full  revenue  service  for  trailing 
vehicles  would  also  need  to  avoid  boarding  passengers  on  the 
failed  vehicle.  In  addition,  for  all  coupling  cases,  the 
station  links  traversed  must  have  sufficient  capacity  to 
contain  as  many  vehicles  as  are  included  in  the  coupled  train. 


Considering  the  very  low  likelihood  of  using  such  procedures 
as  well  as  the  probable  difficulties  in  implementation,  and  the 
questions  of  safety  and  quality  of  vehicle  performance  involved,  we 
recommend  that  the  latter  two  modes  of  failed  vehicle  pushing  which 
include  the  "push  coupling"  entrainment  not  be  implemented.  Rather, 
the  only  model  of  trailing  vehicle  pushing  implemented  would  in- 
volve immediate  deboard  of  passengers  on  both  the  failed  and 
trailing  vehicles.  Since  the  passengers  who  deboard  would 
subsequently  attempt  to  board  the  next  vehicle  passing  on  their 
route,  the  delay  would  not  be  much  more  than  before,  and  pos- 
sibly less  than  if  they  were  deflected  from  their  route  to  the 
maintenance  facility.  It  would  be  more  beneficial  to  model  altern- 
ative methods  of  handling  other  vehicles  in  the  simulation  which 
are  uninvolved  in  the  recovery  effort  since  the  larger  number  of 
other  vehicles  offers  more  potential  to  minimize  overall  passenger 
delay . 


TWO  VEHICLE  RESPONSE  STRATEGIES 

The  implementation  of  this  failure  response  strategy 
involves  the  calculation  of  access  delays,  movement  of  the 
failed  vehicle  to  the  next  station  to  deboard  passengers,  and 
the  movement  of  the  failed  vehicle  to  an  off-line  storage 
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location.  Tow  vehicle  access  delays  include  the  time  required 
to  clear  the  path  between  the  failure  and  the  tow  vehicle 
storage  location,  the  time  required  for  the  tow  vehicle  to 
travel  to  the  failure  location,  and  the  time  required  to  couple 
the  tow  vehicle  to  the  failed  vehicle.  Since  the  tow  vehicle 
is  operated  under  manual  control  and  sometimes  travels  the 
wrong  way  on  one-way  links,  it  will  not  be  modeled  explicitly 
as  a separate  entity.  The  user  will  define  the  path  of  the  tow 
vehicle  from  its  storage  location  to  the  failed  vehicle  in 
terms  of  guideway  links.  At  the  specified  recovery  time,  the 
processor  will  automatically  prevent  additional  AGT  vehicles 
from  entering  the  path  of  the  tow  vehicle  by  failing  the  output 
of  links  that  merge  into  any  links  which  comprise  the  specified 
path.  Occupancy  on  the  links  that  comprise  the  tow  vehicle 
path  will  be  checked  to  determine  when  the  path  is  clear.  Tow 
vehicle  travel  time  will  be  calculated  as  the  sum  of  link 
travel  times  on  the  tow  vehicle  path  multiplied  by  a manual 
control  degradation  factor  specified  by  the  user.  After  the 
path  has  been  cleared  and  the  tow  vehicle  travel  time  plus  the 
user  specified  coupling  delay  has  elapsed,  the  failed  vehicle 
will  start  moving  toward  the  next  station,  and  any  links  which 
were  failed  to  clear  the  tow  vehicle  path  will  be  recovered.  A 
replacement  vehicle  will  also  be  dispatched  at  this  time.  At 
the  next  station  passengers  will  be  deboarded  from  the  failed 
vehicle.  Any  prematurely  deboarded  passengers  will  enter  the 
platform  queue  and  will  complete  their  trips  on  other 
vehicles.  The  failed  vehicle  will  proceed  to  the  maintenance 
facility  where  it  and  the  tow  vehicle  will  remain.  To  document 
the  operation  of  this  failure  response  strategy,  the  following 
information  will  be  printed  out: 

1.  The  time  when  the  tow  vehicle's  path  becomes  clear 


2. 


The  time 
location 


when  the  tow  vehicle  arrives  at  the  failure 


3.  The  time  when  the  failed  vehicle  begins  moving 

4.  The  time  when  the  failed  vehicle  reaches  the 
maintenance  facility  or  siding. 


REPLACEMENT  VEHICLE  RESPONSE  STRATGIES 


The  initiation  of  the  replacement  vehicle  will  be  effected 
as  an  active  fleet  size  modification  with  the  improved 
algorithm  described  in  Section  3.0  on  general  failure  modeling 
improvements.  Replacement  vehicle  response  applies  only  to 
Type  I failures.  When  a replacement  vehicle  is  dispatched  in 
response  to  a Type  I failure,  the  part  of  the  Active  Fleet  Size 
modification  code  which  changes  the  nominal  route  headway  would 
not  be  exercised  because  no  net  change  in  the  fleet  size  occurs. 
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PASSENGER  RESPONSE  STRATEGIES 


It  is  proposed  that  the  passenger  response  to  failures  be 
modified  to  allow  reboarding  of  another  vehicle  (as  a transfer 
trip)  for  passengers  prematurely  deboarded  because  of  a failure 
response  strategy.  The  software  modification  required  is  to 
allow  passengers  to  re-enter  the  platform  queues  as  transfer 
trips  after  prematurely  deboarding  a degraded  vehicle  or  one 
otherwise  affected  by  failure.  Code  currently  exists  to  model 
passenger  transfers  between  scheduled  service  routes.  It  must 
be  verified  that  this  code  is  valid  for  these  unexpected 
transfers  and  for  demand  responsive  service.  Until  detailed 
design  is  completed,  it  is  unclear  how  much  code  will  need 
modification  to  accomplish  this  change;  however,  it  is  known 
that  extensive  sections  of  the  code  will  need  to  be  analyzed  to 
ascertain  that  the  design  changes  are  consistent  with  the 
current  implementation. 


USER  RESPONSE  SELECTION  METHOD 


The  implementation  of  alternative  failure  response 

strategies  will  require  a more  extensive  user  interface 

capability  than  currently  available  in  the  DESM/DPMS.  The 

current  software  distinguishes  between  Type  I and  Type  II 

failures  but  generates  a set  response  to  each  of  these 

failures.  Although  the  full  set  of  user  inputs  for  the 

extended  failure  response  strategies  will  not  be  determined 
until  detailed  design  of  the  software  modifications  is 

complete,  we  anticipate  that  the  following  will  be  chosen  by 

the  user  in  the  failure  specifications. 

*1.  Asynchronous  event  type 

« Failure  . 

• Recovery  . 

• Degradation  . 

• Degradation  recovery  . 


*2.  Time  of  asynchronous  event 

*3.  Failed  entity  - vehicle,  guideway,  or  station 
*4.  If  guideway  link,  starting  and  ending  node  IDs 
*5.  If  station,  station  node  ID 

*6.  If  station,  entire  station  or  station  link  type 
*7.  Entire  link,  link  entry,  or  link  exit 


* Currently  implemented  in  DESM/DPMS 
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* 

* * 


*8.  If  degradation,  degradation  factor 

9.  For  degraded  vehicle  removal,  station  node  ID  of 
intended  maintenance  facility 

10.  Response  of  other  vehicles  in  simulation  to  failure 
or  degradation 

9 Continue  revenue  service. 

• Continue  route  traversal  but  deboard  only. 

• Deboard  all  passengers  at  next  station  then 
circulate  empty. 

Note : For  scheduled  service,  input  this  response 

choice  by  route. 

11.  Recovery  method 

• Under  own  power. 

• Push  by  trailing  vehicle. 

• Tow  by  maintenance  vehicle. 


12. 

If 

tow 

recovery,  link 

numbers  comprising  path  from 

tow 

vehicle  storage  to 

failure 

13. 

Ser 

vice 

continuation  by 

push  vehicle 

**•  Full  revenue  service. 

**•  Route  traversal  but  deboard  only. 

• Deboard  all  passengers  at  first  station  and 
proceed  to  maintenance  facility. 


Currently  implemented  in  DESM/DPMS 
Not  recommended  for  implementation 
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ADDITIONAL  MEASURES  TO  SUPPORT  EXTENDED  FAILURE  MANAGEMENT 


It  is  proposed  that  new  code  be 
provide  the  measures  listed  below  as 
understanding  of  the  effectiveness  of 
response . 


added  to  DESM/DPMS  to 
an  aid  to  the  user's 
the  selected  failure 


Maximum  vehicle  queue  - At  the  time  of  failure 
recovery,  the  vehicle  queue  on  each  guideway  or 
station  link  is  at  a maximum.  Therefore,  code  will 
be  written  to  print  the  queue  occupancy  of  each 
guideway  link  and  each  station  link  in  the  failed 
station,  if  applicable.  From  this  information,  the 
user  can  determine  the  maximum  queue  behind  the 
failure  if,  indeed,  it  extends  beyond  one  link. 
(Note:  The  system  architecture  maintains  separate 

queues  for  each  link.  If  the  queue  of  a downstream 
link  is  full,  the  vehicle  is  forced  to  queue  on  the 
upstream  link . ) 

Vehicle  removal  elapsed  time-code  will  be  written  to 
print  a message  including  the  time,  identity,  and 
location  of  the  failed  vehicle  being  removed  from 
service.  The  user  can  then  calculate  the  elapsed 
time  from  failure  recovery  (the  failed  vehicle 
begins  moving  again)  to  the  time  of  vehicle  removal 
from  the  active  fleet. 


It  is  also  desirable  from  the  user's  viewpoint  to  get  some 
feeling  for  the  time  required  to  fully  restore  service  which 
has  been  defined  in  the  Los  Angeles  DPM  failure  management 
report  as  the  time  to  restore  equal  spacing  of  vehicles.  From 
an  algorithmic  viewpoint,  this  is  a very  difficult  measure  to 
define.  However,  there  is  currently  available  in  the  DESM/ 
DPMS , a debug  flag  which  will  enable  the  printing  of  a message 
defining  the  entry  time  of  each  vehicle  at  each  station.  This 
output  defines  the  station  ID,  route  ID,  next  station,  passen- 
ger loading,  and  several  other  items  at  each  vehicle  entry  into 
each  station.  These  data  may  be  charted  by  the  user  to  obtain 
an  indication  of  the  time  elapsed  until  full  recovery  and  a 
the  effectiveness  of  the  selected  debunching 
restoring  equal  spacing  on  the  routes, 
the  values  of  maximum  and  minimum  interdispatch 
sampling  interval  and  route  can  be  plotted  by  the 
user.  When  the  maximum  and  minimum  values  are  nearly  equal  for 
a route,  it  can  be  assumed  that  equal  spacing  of  vehicles  on 
the  route  has  been  achieved. 


feeling  for 
algorithm  in 
Alternatively, 
time  for  each 


24 


6.0  RECOMMENDED  SOFTWARE  MODIFICATIONS 


The  software  modifications  we  recommend 
modeling  of  failure  response  strategies  in  the 
follows : 


to  improve  the 
DESM/DPMS  are  as 


1.  Implement  additional  scheduled  service  dispatch 
algorithms  to  improve  debunching  control. 

2o  Improve  active  fleet  size  management  for  the  scheduled 
service  case. 

3.  Implement  the  ability  to  include  slack  time  in 
scheduled  service  route  traversal. 

4.  Model  movement  of  degraded  vehicles  to  a user -selected 

maintenance  facility  rather  than  to  the  closest 

station. 

5.  Allow  user  selection  of  failure  response  strategies. 

6.  Model  deboard  only  mode  for  other  vehicles  in  the 

network  during  a failure  situation. 

7.  Model  immediate  deboard  and  empty  circulation  mode  for 

other  vehicles  in  the  network  during  a failure 

situat ion . 

8.  Process  prematurely  deboarded  passengers  as  transfers 
rather  than  completed  trips. 

9.  Model  push  by  the  trailing  vehicle  to  a maintenance 
facility  for  the  failed  vehicle. 

10.  Calculate  tow  vehicle  access  time. 

11.  Produce  additional  measures  of  effectiveness  of 


failure 

response  strategies. 

It  is  our  plan  to  develop  these  software  modifications  in 
sequence  listed  below  in  order  to  enable  phased  testing  and 
of  the  earlier  developed  algorithms  in  earlier  analyses. 

1. 

Items  1 

and 

2 

2. 

Items  4 

and 

8 

3. 

Items  5, 

6, 

and  7 

4. 

Item  3 

5. 

Items  9 , 

10, 

and  11 
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These  software  modifications,  together  with  the  analytical 
techniques  mentioned  in  Section  5.0,  will  support  the  modeling 
of  all  the  failure  response  strategies  indicated  in  Figure  4-1 
for  Type  II  failures.  Nearly  all  of  the  failure  response 
strategies  indicated  in  Figure  4-2  for  Type  I failures  are  also 
supported  by  the  DPMS/DESM  with  the  recommended  modifications. 
Only  the  two  trailing  push  vehicle  responses  which  involve 
making  intermediate  stops  enroute  to  the  maintenance  facility 
are  not  to  be  modeled.  In  Figure  4-2  these  two  alternative 
responses  are  boxed  with  a lighter  line. 
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7.0  TASK  RESOURCES 


Figure  7-1  details  the  schedule  to  accomplish  the  software 
modifications  needed  to  model  the  extended  DPM  failure 
management  strategies.  The  software  modifications  implemented 
under  this  task  will  be  described  in  a memo  report. 
Modifications  to  the  appropriate  software  documents  to  record 
these  and  other  software  changes  will  be  consolidated  under 
Task  3 - Software  Update.  Table  7-1  summarizes  the  estimated 
resources  to  be  expended  in  this  task. 
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FIGURE  7-1.  SCHEDULE,  DPM  FAILURE  MANAGEMENT  - TASK  5.0 

TABLE  7-1.  ESTIMATED  RESOURCES,  DPM  FAILURE 
MANAGEMENT  - TASK  5.0 


Total  Manpower 
man-months* 

Computer  Time 
hour  s 

9.0 

8.7 

*One  man-month  equals  142  applied  man-hours. 
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APPENDIX  A 


REPORT  OF  NEW  TECHNOLOGY 


This  report  aggregates  for  the  first  time  in  Section  4.0 
a variety  of  failure  response  strategies  and  indicates  their 
impact  on  the  unique  modelling  capabilities  embodied  in  the 
System  Operations  Studies  software.  The  specific  new  software 
modification  requirements  are  defined  for  these  strategies  in 
Section  5.0. 
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